Date: Wed, 26 Jan 94 10:08:41 PST From: Ham-Space Mailing List and Newsgroup Errors-To: Ham-Space-Errors@UCSD.Edu Reply-To: Ham-Space@UCSD.Edu Precedence: Bulk Subject: Ham-Space Digest V94 #10 To: Ham-Space Ham-Space Digest Wed, 26 Jan 94 Volume 94 : Issue 10 Today's Topics: Arsene Daily IPS Report - 25 Jan 94 Low Pass filter vs Band Pass - Mode JD Status of polar-orbiting weather satellites Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Space Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-space". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 24 Jan 1994 11:45:07 GMT From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!torn!csd.unb.ca!upei.ca!UPEI.CA!seeler@network.ucsd.edu Subject: Arsene To: ham-space@ucsd.edu Hi - Its been a long time since I've seen anything about Arsene and was wondering if it has any funtions going at all at this time. Tnx - Dave, VY2DCS Internet : Seeler@upei.ca ------------------------------ Date: 24 Jan 94 23:29:06 GMT From: swrinde!sdd.hp.com!think.com!cass.ma02.bull.com!syd.bull.oz.au!brahman!tmx!basser.cs.su.oz.au!metro!news.ci.com.au!eram!dave@network.ucsd.edu Subject: Daily IPS Report - 25 Jan 94 To: ham-space@ucsd.edu IPS RADIO AND SPACE SERVICES AUSTRALIA Daily Solar And Geophysical Report Issued at 2330 UT 24 January 1994 Summary for 24 January and Forecast up to 27 January IPS Warning 02 was issued at 24/2200UT January and is current for period January 27 - 29. ----------------------------------------------------------- 1A. SOLAR SUMMARY Activity: low Flares: none. Observed 10.7 cm flux/Equivalent Sunspot Number : 129/082 1B. SOLAR FORECAST 25 January 26 January 27 January Activity Low Low Low Fadeouts None expected None expected None expected Forecast 10.7 cm flux/Equivalent Sunspot Number : 130/084 1C. SOLAR COMMENT None. ----------------------------------------------------------- 2A. MAGNETIC SUMMARY Geomagnetic field at Learmonth : quiet Estimated Indices : A K Observed A Index 23 January Learmonth 02 2111 0001 Fredericksburg 02 07 Planetary 04 05 2B. MAGNETIC FORECAST DATE Ap CONDITIONS 25 Jan 08 Quiet to unsettled. 26 Jan 08 Quiet to unsettled. 27 Jan 20 Unsettled to active. 2C. MAGNETIC COMMENT Active periods expected during interval 27-29 Jan due to coronal hole. 3A. GLOBAL HF PROPAGATION SUMMARY LATITUDE BAND DATE LOW MIDDLE HIGH 24 Jan normal normal normal PCA Event : None. 3B. GLOBAL HF PROPAGATION FORECAST LATITUDE BAND DATE LOW MIDDLE HIGH 25 Jan normal normal fair 26 Jan normal normal fair 27 Jan normal fair poor 3C. GLOBAL HF PROPAGATION COMMENT Degraded comms expected at mid/high lats during interval 27-29 January. ----------------------------------------------------------- 4A. AUSTRALIAN REGION IONOSPHERIC SUMMARY MUFs at Sydney were about 15% above predicted monthly values T index: 73 4B. AUSTRALIAN REGION IONOSPHERIC FORECAST DATE T-index MUFs 25 Jan 75 About 15% above predicted monthly values. 26 Jan 75 About 15% above predicted monthly values. 27 Jan 75 About 15% above predicted monthly values. Predicted Monthly T Index for January is 30. 4C. AUSTRALIAN REGION COMMENT Degraded HF comms expected during Jan 27-29. -- Dave Horsfall (VK2KFU) VK2KFU @ VK2OP.NSW.AUS.OC PGP 2.3 dave@esi.COM.AU ...munnari!esi.COM.AU!dave available ------------------------------ Date: Mon, 24 Jan 1994 11:53:17 GMT From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!torn!csd.unb.ca!upei.ca!UPEI.CA!seeler@network.ucsd.edu Subject: Low Pass filter vs Band Pass - Mode JD To: ham-space@ucsd.edu I have some desensing of my 440 rig on receive when the 2 meter rig fires up on Mode JD. This is not a MAJOR problem but I would like to resolve it. I suspect that it involves the 3rd harmonic of the 2 meter Transmitter. The books suggest using a low pass or band pass filter - but they differ as to which would be best ( opinion or operation differences?). I use the all IC275 for Dx and local operations as well and suspect that the low pass filter would be a good start. The filter in the VHF/UHF Dx book appears to fit my needs - 35? db attenuation of the 2nd harmonic and 60 db attenuation of the 3rd - with minimal (?) insertion loss. My questio is this - is the low pass filter the best way to solve this particular issue - and if so - does anyone have any suggestions as to any particular filter design / schematics - and comments as to how they/it works? Thanks for considering this post. Dave, VY2DCS Internet: Seeler@upei.ca ------------------------------ Date: Tue, 25 Jan 94 17:46:00 +0200 From: swrinde!cs.utexas.edu!howland.reston.ans.net!pipex!uknet!EU.net!news.eunet.fi!gate.compart.fi!compart!leo.wikholm@network.ucsd.edu Subject: Status of polar-orbiting weather satellites To: ham-space@ucsd.edu STATUS OF POLAR-ORBITING WEATHER SATELLITES =========================================== No. 2, January 25, 1994 Station: Helsinki, +60.2N +25.1E ------------------------------------------------------ NOAA 9 137,62 MHz normal NOAA 10 137,50 MHz VHF conflict with NOAA 12? NOAA 11 137,62 MHz normal NOAA 12 137,50 MHz normal Meteor 3-5 137,30 MHz not actice in North Meteor 2-21 137,30 MHz not active in North ------------------------------------------------------ Leo Wikholm internet: leo.wikholm@compart.fi fidonet : 2:220/861 ------------------------------ Date: 24 Jan 94 09:24:44 -0700 From: ucsnews!newshub.sdsu.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!sol.ctr.columbia.edu!hamblin.math.byu.edu!yvax.byu.edu!physc1.byu.edu!peterson@ To: ham-space@ucsd.edu References <2hd6ji$q5e@hpavla.lf.hp.com>, <1994Jan17.145311.25166@ke4zv.atl.ga.us>, tr.colu Subject : Re: Vacuum tubes in spacecraft? In article , dts@world.std.com (Daniel T Senie) writes: > In article <1994Jan17.145311.25166@ke4zv.atl.ga.us> gary@ke4zv.atl.ga.us (Gary Coffman) writes: >>Note also that program bloat can be traced almost completely to having >>excess RAM available. Programs naturally expand to fill the space available, >>witness Wordstar. It was a great fast program on a 48 kb Z-80 system, but > > common misconception. Wordstar NEVER fit in 48K. Sure it would run in a > machine that had 48K, but every time you hit ^Y to delete a line, it > had to swap in an overlay from disk to do the function, then swap back > to the main code. When more memory is available, it is possible to > improve performance. > >>now it's a multi-megabyte dog on a Windows PC with 8+ megs of RAM. And >>that's 166 times more RAM to develop a bit error that can crash the system. >>To a large degree, reliability is a function of parts count. The fewer >>parts, the less to go wrong. >> > > Actually in software the less is better philosopy does not always hold. To > get program size smaller, one could always skip the bounds checking and input > parameter checking. Fewer parts, but less reliability... > >>Gary >>-- >>Gary Coffman KE4ZV | You make it, | gatech!wa4mei!ke4zv!gary > > -- > --------------------------------------------------------------- > Daniel Senie Internet: dts@world.std.com > Daniel Senie Consulting n1jeb@world.std.com > 508-365-5352 Compuserve: 74176,1347 Actually there are two other driving forces in the software bloat that are only allowed to operate because of the cheap RAM: 1) The demand for software that requires no thought or training. Some of this is good and some of it is useless "creeping featurism" (I have yet to understand why a top quality word processing package would require you to remove your hands from the keyboard to perform basic formatting functions). And 2) the trend toward using high-level languages for all software development. Most of those "lean and mean" packages of the past were written in optimized assembly code because RAM was tight. Now they don't have to put any effort into optimizing the code and are able to write using high-level languages and compilers that generate absolutely horrendous code (from an efficiency standpoint). Yes, that allows them to meet the demands of (1) above more quickly but at a tremondous cost in storage space (just for grins look at the bloat in the distribution disks for ANY package over the last few years - things that used to be delivered on 2 360K floppies now require 4 to 6 1.44M floppies and add data compression to boot). Whether this whole trend is good or bad is a totally religious argument (hardware is cheap and features are nice versus why do I need so much hardware just to run a simple application). However, any way you look at it my hat goes off to the programmers who are able to fit the entire control program for the Shuttle into the memory on those computers. I can guarantee they are not using the bloated high-level languages that you normally see in the PC world to do that. Bryan Peterson, ki7td peterson@physc1.byu.edu ------------------------------ End of Ham-Space Digest V94 #10 ******************************